@jreynard-code I don't have enough knowledge of the back-end for this review, I'll let the other devs approve it :)
Btw, did you generate these changes with the GitHub Copilot agent or something similar? The build, test and lint workflows were triggered 15 times 😅

The build, test and lint workflows were triggered 15 times 😅

Seems ok to me. They are triggered multiple time for each sub-module of the api, there's a matrix job in the workflows.

The build, test and lint workflows were triggered 15 times 😅

Seems ok to me. They are triggered multiple time for each sub-module of the api, there's a matrix job in the workflows.

Oh ok, thanks for the answer 😄

From generated clients (TS and python) users will have a error compatibility issue migrating from 5.0.0 to 5.0.1 client.

@jreynard-code I'm not sure I understand the impact of this... If a webapp uses client v5.0.0, will it work with a deployed API v5.0.1? (and vice-versa?)
Or do you mean only some calls to the API previously working with v5.0.0 will stop working in v5.0.1? (e.g. creating a workspace with the option datasetCopy defined)

From generated clients (TS and python) users will have a error compatibility issue migrating from 5.0.0 to 5.0.1 client.

@jreynard-code I'm not sure I understand the impact of this... If a webapp uses client v5.0.0, will it work with a deployed API v5.0.1? (and vice-versa?) Or do you mean only some calls to the API previously working with v5.0.0 will stop working in v5.0.1? (e.g. creating a workspace with the option datasetCopy defined)

In a nutshell:

• clients 5.0.0 will continue to work with API 5.0.0 and 5.0.1
• clients 5.0.1 will continue to work with API 5.0.0 and 5.0.1
• WorkspaceCreateRequest/WorkspaceUpdateRequest and Workspace objects will no more handle datasetCopy property in 5.0.1. So if this property is explicitly set in ETLs/Webapp, users will have to remove it once they use 5.0.1 clients